プロジェクトリスク検知のヒント

「プロジェクトのリスクを洗い出しきれていますか？」

この問いに自信を持って「Yes」と即答できる方は以降を確認いただく必要はありません。

「No」もしくは「Yes」と答えるのにちょっと躊躇した方はざっと目を通していただけると、何らかの気づきがあるかもしれません。

ここからは、独立行政法人情報処理推進機構（IPA）が公開している資料を紹介していきたいと思います。

紹介資料

資料名：ITプロジェクトのリスク予防への実践的アプローチ

利用対象者：情報システムの企画、情報システムのプロジェクトマネージャー、PMO、設計者等

特徴：ITプロジェクト目標達成を阻害する事柄をリスクととらえ、リスクとそのリスク発現の要因を中心にすえ、リスクの発現を防ぐために”リスク発現の要因”に対してどのような予防策を打つかその予防策の効果をどのようにとらえるかと”リスク発現の要因”に対してその兆しをどう把握するかの関係を明確にしたものです。

リスクとリスクマネジメント

リスクの定義

PMBOKでは、リスクを次のように定義しています。

それが発生すれば少なくともスコープ、スケジュール、コスト、品質といったプロジェクト目標に影響を与える不確実な事象・状態

• 「不確実な事象」なので、必ず発生するもの・すでに発生してしまったものは「リスク」に該当しません。これらは「問題・課題」です。
• 「プロジェクト目標に影響を与える」リスクは、「マイナスのリスク」だけでなく、「プラスのリスク」も存在します。ITプロジェクトにおいてはマイナスのリスクが主な管理対象になるかと思います。

リスクマネジメントのプロセス／流れ

PMBOKに定義されているプロセスは以下のとおりで、これらをプロジェクトの開始から終了まで繰り返すことになります。

1. リスク・マネジメントの計画：リスクマネジメント活動全般の実行方法の計画
2. リスクの特定：リスクの洗い出し、文書化
3. リスクの分析(定性的・定量的)：影響の等級付け・優先順位付け
4. リスク対応の計画：各リスクへの対応策を策定
5. リスク対応策の実行
6. リスクの監視：リスク監査（リスクマネジメント活動や対応策の有効性）、リスク再査定（新たなリスクの特定、古くなったリスクの終結）

本記事の対象／用語定義

本記事の対象範囲

本記事ではリスクマネジメントプロセスの『２．リスク特定』について記載します。他のプロセスについては特段触れません。

「ITプロジェクトのリスク予防への実践的アプローチ」には、『４．リスク対応の計画』で策定するリスクの予防策に関する説明も記載されています。

用語注釈

使用する用語について説明します。

• リスク事象：プロジェクトにおいて発生する可能性のある望ましくない出来事
  • 適切な対処をとれないとQCDの目標達成の阻害要因となり得る。
• リスク事象ドライバ：特定のリスク事象を誘発しうる要因
  • 例）「要件獲得の対象とすべきユーザー側の対象者が正しく特定できていない」というリスク事象ドライバが要件定義プロセスにおいて存在した場合、「要件定義に漏れが生じる」というリスク事象が発生しうる。
  • リスク事象ドライバが存在しているからといって、そのドライバと因果関係にあるリスク事象が必ず発生するわけではない。

リスク事象ドライバ

リスク事象の発生原因になり得る24個のリスク事象ドライバを紹介します。加えて、誘発しうるリスク事象とリスク事象ドライバの主な把握観点も記載します。

１．システム化の目的が明確でない

• リスク事象：要件の増大、もしくは絞り込みの不全が発生し、プロジェクトが統制できなくなる
• 把握観点
  • システム化の目的が文書化されているか
  • 定量的な達成指標が文書化されているか

２．現行機能の調査・確認が不足している

• リスク事象：受け入れテスト時に不具合指摘が多発しプロジェクトの中断または大量の仕様変更が発生してコストが超過する
• 把握観点
  • 業務要求と現行システムの関係を説明できるメンバーの有無
  • 現行システムの設計書が最新化されているか
  • 要件定義書に「現行どおり」という記載があるか

３．現行システムとそのドキュメントが整合していない

• リスク事象：現行システムから引き継ぐべき要件に漏れが発生する
• 把握観点
  • 現行システムに関する各種ドキュメントが存在するか
  • サンプルチェックによる網羅性・整合性の度合いが一定以上か

４．パッケージ選定に関する検討が十分でない

• リスク事象：機能の要求を満たせないことや性能が出ないことにより、大きな手戻りが発生し稼働不能になる
• 把握観点
  • 選定における機能条件、非機能条件、運用条件が明確に文書化されているか
  • 検討経緯が明確か

５．性能の検討が十分でない

• リスク事象：利用に供する性能が出ないため、稼働不能や大規模改修に繋がる
• 把握観点
  • 性能見積りの前提となるデータ量に関する資料の有無
  • 実装過程における性能に関する進め方について、妥当性があるか

６．可用性の検討が十分でない

• リスク事象：安定稼働の保証がないため、稼働不能や大規模改修に繋がる
• 把握観点
  • 目標とする稼働率、可用性確保の方式が明確か
  • 稼働率の見積り方法は妥当か

７．運用要件の検討が十分でない

• リスク事象：実現できない、矛盾を含んだ要求仕様ができる（運用要件）
• 把握観点
  • システム運用関連の検討が行われているか
  • システム運用関連の成果物の作成が計画されているか

８．運用に向けての制約条件が明確でない

• リスク事象：期待された業務運用ができない
• 把握観点
  • 運用担当者によるレビューが行われているか
  • 業務視点でのウォークスルー、テストが計画されているか

９．要件を獲得すべきステークホルダーが網羅されていない

• リスク事象：要件の漏れが発生する（後になってステークホルダーから指摘される）
• 把握観点
  • ステークホルダーのリストの有無
  • ステークホルダー全員にヒアリングを実施しているか

１０．システム部門による要件とりまとめが十分でない

• リスク事象：要件がいつまでも確定しない、あるいは要件が想定以上に膨らむ
• 把握観点
  • 要件の引き出しプロセスが明確になっているか
  • 要件のとりまとめ様式が定義されているか

１１．ドキュメントの更新が管理されていない

• リスク事象：追加・改修開発時に、現行システムから引き継ぐべき要件に漏れが発生する
• 把握観点
  • 変更管理手順が規定され、実践されているか
  • 要件変更・ソースコード修正時にドキュメント修正およびレビューを実施しているか

１２．仕様の変更管理ができていない

• リスク事象：規模の肥大化、費用に関するPJ の目標未達
• 把握観点
  • 仕様変更一覧の有無
  • 仕様変更に仕組み（フロー、会議体）が規定されているか

１３．ユーザーによる仕様の確認が十分でない

• リスク事象：要件の漏れや認識の齟齬が生じる
• 把握観点
  • 現場ユーザによるドキュメントレビューが適切に行われているか
  • 要件定義完了時点でステアリングコミッティが開催されたか

１４．要求の優先度が曖昧になっている

• リスク事象：開発規模が膨張する
• 把握観点
  • 要求に優先度付けを実施しているか
  • 要求の優先度をお客様に確認しているか

１５．業務要件の網羅性が検証できない

• リスク事象：画面、帳票等の形式的、定型的な情報はあるが、業務の全体にわたる要件や要望、今後の展望などがあいまいになる
• 把握観点
  • 現行の画面や帳票以外から業務要件を把握するための人的な体制が準備されているか
  • 業務視点でのウォークスルーがスケジュールされているか

１６．設計と実業務の整合性が検証できていない

• リスク事象：業務に合わない情報システムになる（要件定義に漏れが発生する）
• 把握観点
  • 業務面と情報システム面の双方から点検（ウォークスルー）し、業務に対する機能の解釈の誤りの有無について確認しているか

１７．経営層によるプロジェクト運営の関与が十分でない

• リスク事象：要件定義を始めとする工程の節目や重要な意思決定場面で、優先順位やリソース配分に対する方向性が決まらないため、プロジェクトの意思決定が誤ったものとなる
• 把握観点
  • プロジェクト憲章が作成されているか／承認されているか
  • 経営層がプロジェクトに対し月次報告などを要求しているか

１８．経営層によるスコープ決定への関与が十分でない

• リスク事象：調整の不調による費用の膨張や要件定義の誤り
• 把握観点
  • 要件の変更時に、及ぼす影響に応じた責任者の承認を得るルールが存在するか

１９．経営層がパッケージ導入の意図・目的を明示していない

• リスク事象：パッケージ導入でカスタマイズ仕様が膨張する
• 把握観点
  • パッケージの採用方針（導入意図や、現行業務維持方針など）について、プロジェクト企画書などの公式文書に記載しているか
  • カスタマイズに関する制約条件（コストや工数の上限など）について、プロジェクト企画書などの公式文書に記載しているか

２０．ステークホルダー間の力関係がアンバランスである

• リスク事象：全体最適が実現しないことによるQCD の乱れ
• 把握観点
  • 納期折衝・スコープ調整の余地がない
  • 異なる役割を持つステークホルダー間で指導・統括・評価関係がある

２１．高次の調整・決定機関が機能していない

• リスク事象：重要事項の決定が遅れたり、調整できなかったりする
• 把握観点
  • ステアリングコミッティにあたる機構が存在しない
  • ステアリングコミッティの開催要件(定期開催サイクル、開催条件など)が定義されていない

２２．十分なコミュニケーションがとれていない

• リスク事象：作業効率の悪化により工程の進捗が遅れる
• 把握観点
  • 会議体が定義されているか
  • 課題管理とエスカレーションに関するルールが規定されているか

２３．業務用語が共有されていない

• リスク事象：要件定義・設計上の誤謬による手戻りや品質問題が発生する
• 把握観点
  • （開発者向け）業務用語に関する注釈付きドキュメントの有無
  • （ユーザ向け）システム用語に関する注釈付きドキュメントの有無

２４．業務知識が不足している

• リスク事象：仕様変更、仕様追加の多発により、サービス開始の遅れや品質の極端な悪化を招く
• 把握観点
  • ユーザ側：キーマンが明確であるか／要件定義に参画しているか
  • ベンダー側：現行業務を現場レベルで調査しているか

感想

先人たちの経験が集約された、非常に参考になる内容でした。日々の業務（特に案件の初期段階）で活用したいと思います。